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The challenge of the Reengineering Case 14J is to extract a state machine model out of the abstract 
syntax graph of a Java program. The extracted state machine offers a reduced view on the full 
program graph and thus helps to understand the program regarding the question of interest. We 
tackle this task employing the general purpose graph rewrite system GrGen.NET (www . grgen . net^ . 

1 What is GrGen.NET? 

GrGen.NET is an application domain neutral graph rewrite system m, the feature highlights regarding 
practical relevance are: 

Fully Featured Meta Model: GrGen.NET uses attributed and typed multigraphs with multiple inher- 
itance on node/edge types. Attributes may be typed with one of several basic types, user detined 
enums, or generic set, map, and array types. 

Expressive Rules, Fast Execution: The expressive and easy to learn rule specification language allows 
straightforward formulation of even complex problems, with an optimized implementation yield- 
ing high execution speed at modest memory consumption. 

Programmed Rule Application: GrGen.NET supports a high-level rule application control language. 
Graph Rewrite Sequences (GRS), offering sequential, logical, iterative and recursive control plus 
variables and storages for the communication of processing locations between rules. 

Graphical Debugging: GrShell, GrGen.NET's command line shell, offers interactive execution of 
rules, visualizing together with yComp the current graph and the rewrite process. This way you 
can see what the graph looks like at a given step of a complex transformation and develop the next 
step accordingly. Or you can debug your rules and sequences. 

2 The Core Assignment 

The task of the core assignment is to extract a state machine model out of the abstract syntax graph of a 
Java program. The task stems from the domain of reengineering where software engineers need to gain 
insights into legacy systems, which is a lot easier given a birds eye view on the high level structure (and 
thus behavior) of the program. The aim of the task is to evaluate the solutions and the tools backing them 
regarding performance and scalability, with a domain leading naturally to large graphs to be considered; 
and especially to evaluate the solutions and tools regarding the ability to - and conciseness in - carrying 
out complex, non-local matchings of graph elements, requiring the matching of recursive graph struc- 
tures. Before the extraction can take place, the Java program graph needs to be imported from an Ecore 
file describing the source metamodel and an XMI file specifying the graph. Afterwards the resulting 
state machine has to be exported into an XMI file conforming to a given Ecore file describing the state 
machine metamodel. 
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Figure 1 : Processing steps of the model extraction. The extraction and the XMI export are written in 
GrGen.NET languages. Import is handled by a supplied import filter, which generates GrGen meta model 
files ( . gm) as an intermediate step. 

2.1 Importing the Graph 

As GrGen.NET is a general purpose graph rewrite system and not a model transformation tool, we do 
not support importing Ecore metamodels directly. Instead, we supply an import filter generating an 
equivalent GrGen-specific graph model (.gm file) from a given Ecore file by mapping classes to GrGen 
node classes, their attributes to corresponding GrGen attributes, and their references to GrGen edge 
classes. Inheritance is transferred one-to-one, and enumerations are mapped to GrGen enums. Class 
names are prefixed by the names of the packages they are contained in to prevent name clashes; the 
same holds for references which are prefixed by their node class name. Afterwards the instance graph 
XMI adhering to the metamodel described in the Ecore file thus adhering to the just generated equivalent 
GrGen graph model is imported by the filter into the system to serve as the host graph for the following 



extractions, i.e. transformations. The entire process is shown in Figure 1 above. 



2.2 Extracting the States 

The transformation is done in two steps, the first creates the states of the state machine, and the second 
inserts the transitions in between. Each step consists of the application of one rule (utilizing a subpattern) 
on all matches found, giving a direct correspondence between coding conventions and rules. 

Let us start with a short introduction into the syntax of the basic constructs of the rule language: 
Rules in GrGen consist of a pattern part specifying the graph pattern to match and a nested rewrite 
part specifying the changes to be made. The pattern part is built up of node and edge declarations or 
references with an intuitive syntax: Nodes are declared by n:t, where n is an optional node identifier, 
and t its type. An edge e with source x and target y is declared by x -e : t-> y, whereas — > introduces 
an anonymous edge of type Edge. Nodes and edges are referenced outside their declaration by n and 
-e->, respectively. Attribute conditions can be given within if -clauses. 

The rewrite part is specified by a replace or modify block nested within the rule. With replace- 
mode, graph elements which are referenced within the replace-block are kept, graph elements declared in 
the replace-block are created, and graph elements declared in the pattern, not referenced in the replace- 
part are deleted. With modif y-mode, all graph elements are kept, unless they are specified to be deleted 
within a delete () -statement. Attribute recalculations can be given within an eval-statement. These 
and the language elements we introduce later on are described in more detail in our solution of the Hello 
World case ||2l, and especially in the extensive GrGen.NET user manual |[T1. 
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Now let us have a look at the code to create the states (here and in the following rules the prefixes from 
name mangling were removed due to space constraints): 

rule createStates 
{ 

stateClass : Class ; 

stateClass - : annotationsAndModif iers -> : Abstract ; 
if {. StateClass . name == "State"; > 

es:CreateStates(stateClass); 

modify { 

sm : StateMachine ; 
es (sm) ; 

} 

} 

We search for the abstract class of name State as starting point and create the state machine which 
will receive the states and transitions found. The real work is done in a subpattern CreateStates, of 
which an instance es is declared and thus searched from the found stateClass on; or better in the 
rewrite part of this subpattern, which is applied with rule call syntax passing the just created State- 
Machine node: 

pattern CreateStates (parentClass : Class) modi/t/ ( sm : StateMachine ) 
{ 

iterated {. 

extendingClass : Class -: extends -> r : NamespaceClassifierReference ; 
r - : classif ierRef er ence s -> cr : Clas sif ierRef er ence ; 
cr -: target -> parentClass; 

es: CreateStates (extendingClass ) ; 

optional {. 
negative { 

extendingClass -: annotationsAndModif iers -> : Abstract ; 

} 

modify {. 

sm -:states-> s:State; 

s -:link-> extendingClass; 

eval { s . name = extendingClass . name ; > 

} 

} 

modify { 
es ( sm ) ; 

} 

} 

modify {. > 

} 

The subpattern searches a class directly extending the given parent class passed as a parameter, i.e. 
it descends one subtyping step downwards in the type hierarchy. It matches into breadth with the it- 
erated construct to get all such extending classes; the iterated matches all instances of its contained 
pattern which can be found in the host graph. Then the subpattern matches further into depth by call- 
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ing itself recursively with the just matched extending class as parameter, this way we cover the entire 
type hierarchy from the parent class on. In the optional case the class is not abstract a state is created 
within the state machine and a link edge is created linking the state with the class (the link edges are 
additional helper edges introduced to store the traceability relation between source and target nodes). 
The optional matches the contained pattern if it is available in the host graph. The negative causes 
matching of the containing pattern to fail if its pattern can be found in the host graph. 



2.3 Extracting the Transitions 



The transitions are inserted with a second rule given in Figure 2 utilizing the subpattern given in Figure 3 
We search for the class . Instance () . activate () pattern in the graph, if found we know the target 
state from the class of the called method and the link between the class and the state we inserted previ- 
ously. Then we search with the subpattern FindSourceState for the source state, which gets yielded 
[^into the def pattern element sourceState. If this was found we add a Transition in between the 
source state and the target state, and link it to the expressionStatement containing the method call. 

The subpattern is used to recursively waUc outwards from the method call to the class containing the 
call (recursive ascent over statement nesting); passing over the different types of statements and statement 
containers which might be on the way, until the class is reached yielding it back. The statements passed 
are all linked to the transition, which will be helpful for the extension tasks. 



2.4 Extension Tasks 

The trigger attributes of the transitions are filled by four rules for the four different ways specified; they 
get executed one after the other (this way handling the priority), first the non-run method, then the switch 
case, then the catch block and finally the fallback rule. Due to the links from the transitions to all the 
constructs on the path from the method call to the containing class this is a simple local pattern search. 



as can be seen in Figure 4 



The action attributes of the transitions are filled by two rules for the two different ways specified; 
first the enum value used in a send method, then the fallback rule. Again this is a simple local pattern 
search due to the links from the transitions to all the constructs on the path from the method call to the 



containing class, cf. Figure 5 



2.5 Exporting the State Machine 



A visualization of the resulting state machine is given in Figure 6 The XMI export of this graph is 



handled by 5 additional rules given in export . gri containing emit statements: one for assigning XMI 
ids to the elements to be exported, which are stored in a map from the nodes to the corresponding ids, two 
for writing the XMI prefix and suffix, one for writing the States and one for writing the Transitions, 
utilizing the previously computed node to id mapping. 



3 Rule Control, Performance, and Visualization 

The extraction process is controlled by the graph rewrite script reengineering . grs which is executed 
by the GrShell; the script contains the following lines: 

' The yield-keyword is used to open a block with yielding assignments, and as a mandatory annotation at an entity whenever 
it is yielded to. 
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import primitive_types . ecore java.ecore StateMachine . ecore 
l_small -model . xmi reengineering . grg 

xgrs [createStates] 

xgrs [ cr eat eTr ans it ions ] 

xgrs [ addTr iggerNonRunMethodName ] ;> [ addTr igger Swi t chCaseEnumValueName ] \ 

;> [ addTr iggerCat chBlockExc ept i onClas sName ] ;> [addTriggerOtherwise] 
xgrs [addActionSend] ;> [ addAct i onO therwi se ] 

The import command imports the XMI input graph complying to the Ecore models, and additionally 
includes the rules given in the rule file. The xgrs keyword starts an extended graph rewrite sequence, 
which is the rule application control language of GrGen (prepending debug before xgrs allows you to 
debug the sequence execution in GrShell). The rules are executed on all the matches found, which is 
requested by the all-bracketing [rule] . The then-right operator ; > executes the left sequences, then the 
right sequence, and returns as sequence result the result of the right sequence; the sequence results are 
irrelevant for this task, in general they are used to control sequence applications. 



3.1 Performance 

The benchmark results for the extraction task are given in the following table. 
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Table 1: Results for different input sets; running time in ms, memory usage in MiBytes. 



The reported values are computed as the arithmetic mean of the middle 3 values out of 5 measurements, 
on a Core i7 920 (2.6GHz) with 6 GiBytes of main memory under Windows Vista 64 Bit with MS .NET 
64 Bit for the upper part of the table and on a Core 2 Duo U9600 (1.6GHz) with 3 GiBytes of main 
memory under Windows 7 32 Bit with MS .NET 32 Bit for the lower part. Import time is the time 
needed for importing the graph, import size is the size of the heap after importing the graph. Shell time 
is the time needed to transform the imported graph from API level (as seen by an external program using 
the API) into a named graph as employed by the GrShell of the rapid prototyping environment, shell size 
is the size of the heap after the named graph was constructed. Extraction time is the time needed for the 
application of the extraction rules. Remark: the dominating component of the extraction time is the time 
needed by the .NET just-in-time compiler producing machine code out of the .NET bytecode. 



3.2 Visualization 

The GrShell utilizes the graph viewer yComp as its visualization component; the final state machine 
visualization was already presented in |Figure"6 But in addition to the state machine, yComp is able to 
give a decent visualization of the original program graph, too, as you may see in Figures|7][8]and|9]which 
give a series of images zoomed in, an outstanding help in understanding and debugging. 



Edgar Jakumeit and Sebastian Buchwald 



173 



This is made possible by the high configurability of yComp: one can choose from several available 
layout algorithms, e.g. organic for a force-based layout, or hierarchic which works well for program 
graphs (it was used in rendering the syntax graphs shown in this paper). For every available node or edge 
type it can be configured in which color with what node shape or edge style it should be shown, with 
what attribute values or fixed text as element labels or tags it is to be displayed, or if it should be shown 
at all. Furthermore graph nesting can be configured by registering edges at certain nodes to define a 
containment hierarchy, causing the nodes to be displayed as subgraphs containing the elements to which 
they are linked by the given edges. In |Figure"TO an excerpt from our configuration file for customizing 
the graph layout of the program graph is shown. In addition a helper edge introduction step was added, 
so that all expression nodes are nested inside their containing statements, not only the outermost ones. A 
helper step was used in producing the final state machine visualization Figure 6[ too, replacing Transition 
nodes with real edges. 



4 Conclusion 



In this paper we presented a GrGen.NET solution to the Reengineering challenge of the Transformation 
Tool Contest 2011 (which is available as a SHARE image [5]). The abstract Java syntax graph con- 
forming to the j ava . ecore metamodel was imported by a supplied import filter under remapping to the 
graph concepts supported by GrGen; the extracted state machine was exported by a handful of text emit- 
ting graph rewrite rules. The name mangling Ecore/XMI import and the explicitely programmed XMI 
export, which result from the fact that GrGen is not a dedicated model transformation tool, are the only 
points of our solution we regard to be rather weak. In contrast to the declarative graph rewriting with 
recursive and iterated structures (see 1 3 J for more on this) which we employed to extract a state machine 
giving a high level overview out of the original syntax graph. This ability of matching and rewriting 
recursive patterns allowed us to give a concise and simple solution to the core task of the Reengineering 
challenge closely following the specification given, with rules matching kernel patterns and subpattem 
recursion and iteration to match recursive structures into depth and breadth. During rewriting of the re- 
cursive match for transition creation, from the activation call to the containing class outwards, links were 
inserted from the transition to the elements visited; besides having been a help in debugging they espe- 
cially allowed to easily solve the extension task with purely local graph rewrite rules (we could have used 
storagemaps instead of storing and retrieving this tracebility information as other tools have done, but 
using edges allows for easy, visual debugging). The extraction resulted in correct target state machines 
for all input graphs supplied; for the large graph it took about 200ms, i.e. performance is an order of 
magnitude better than the reference solution. The goal of the task is to allow program understanding by 
extracting and displaying a reduced, easily understandable model. In addition to visualizing this simple 
model we have presented a visualization of the original program graph with our graph viewer yComp; 
utilizing color customization and especially nesting subgraphs inside nodes, we managed to achieve an 
understandable visualization for the two medium sized example graphs (7000 nodes plus 7000 edges), 
which a reengineer can inspect and navigate in order to develop and debug his transformation rules. 



References 



[1] Jakob Blomer, Rubino GeiB & Edgar Jakumeit (201 1): The GrGen.NET User Manual. ,http : //www . grgen . 
Eetl 



174 



Solving the TTC 201 1 Reengineering Case with GrGen.NET 



[2] Sebastian Buchwald & Edgar Jakumeit (201 1): Saying Hello World with GrGen.NET - A Solution to the TTC 
2011 Instructive Case. In Van Gorp et al. |6|. 

[3] Berthold Hoffmann, Edgar Jakumeit & Rubino GeiB (2008): Graph Rewrite Rules with Structural Recur- 



sion. 2nd Intl. Workshop on Graph Computational Models (GCM 2008). ' http : //www. inf ormatik 
'uni-bremen . de/~hof /papers/08-GCM . pdf '. 

[4] Tassilo Horn (201 1): Program Understanding: A Reengineering Case for the Transformation Tool Contest. In 
Van Gorp et al. [6 j. 

[5] Edgar Jakumeit & Sebastian Buchwald (2011): SHARE demo related to the paper Solving the TTC 



2011 Reengineering Case with GrGen.NET. http : //is . ieis . tue .nl/staf f /pvgorp/shaxe/?page= 
^Conf igureNewSession&:vdi=XP-TUe_TT Cll_GrGen_v2.vdi; 

[6] Pieter Van Gorp, Steffen Mazanek & Louis Rose, editors (201 1): TTC 2011: Fifth Transformation Tool Con- 
test, Zurich, Switzerland, June 29-30 2011, Post-Proceedings. EPTCS. 



A Code Listings and Screenshots 



rule cr eat eTr ans it ions 
{ 

expressionStatement : ExpressionStatement -: expression -> refTargetClass ; 
refTargetClass : IdentifierReference - : target -> targetClass : Class ; 
refTargetClass -:next-> calllnstance ; 

calllnstance : MethodCall -:target-> instance : ClassMethod ; 
calllnstance -:next-> callActivate ; 

callActivate : MethodCall -:target-> act i vat e : Clas sMethod ; 

if { inst ance . name ==" Inst ance " && act i vat e . name ==" act i vat e " ; } 

targetClass <-:link- targetState : State ; 
def sourceState : State ; 

f s s : FindSour c eSt at e ( expr e s s ionSt at ement , yield sourceState); 
sm : StateMachine ; 
modify { 

sm -: trans it ions -> transition : Transition ; 
sourceState <-:src- transition -:dst-> targetState; 
sourceState -:out-> transition <-:in- targetState; 
transition -:link-> expressionStatement; 
f ss ( trans it ion ) ; 

> 

> 



Figure 2: Rule for creating transitions 
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pattern FindSourceState (containedEntity : Node , def sour ceState : State ) 

wiodi/j/ (transition: Transition) 

{ 

alternative { 

StatementListContainer {. 

listContainer : StatementListContainer -: statements -> containedEntity ; 
fss : FindSourceState ( listContainer , yield sourceState ) ; 
modify { 

transition -:link-> listContainer; 
f ss ( trans it ion ) ; 

} 

> 

StatementContainer ■[ 

container : StatementContainer -: statement -> containedEntity; 
fss : FindSourceState ( container , yield sourceState); 
modify { 

transition -:link-> container; 

f ss ( trans it ion ) ; 

} 

} 

StatementSwitch ■[ 

swit ch : Swit ch -:cases-> containedEntity; 

f ss : FindSourceState ( switch , yield sourceState); 

modify { 

transition -:link-> switch; 

fss (transition) ; 

} 

} 

StatementCondition { 

condition : Condition - : elseStatement -> containedEntity; 
fss : FindSourceState ( condition , yield sourceState); 
modify { 

transition -:link-> condition; 

fss (transition) ; 

} 

} 

StatementTry {. 

try:TryBlock - : catcheBlocks -> containedEntity; 
fss : FindSourceState (try , yield sourceState); 
modify -[ 

transition -:link-> try; 

fss (transition) ; 

} 

} 

Class i 

cc:Class -:members-> containedEntity; 
ss: State -:link-> cc ; 
yield {. yield sourceState = ss; } 
modify { 

transition -:link-> cc ; 

} 

} 

} 

} 



Figure 3: Subpattem for creating ti-ansitions 
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rule addTr IggerNonRunMethodName 
{ 

transition : Transition -:link-> method : ClassMethod ; 
if ■[ method . name != "run"; } 

modify { 

aval {. transition . trigger = method . name ; } 

} 

} 

rule addTr iggerSw it chCaseEnumValueName 
{ 

transition : Transition -:link-> case : NormalSwitchCase ; 
case -: condition -> caseCondit ion : Ident if ierRef erence ; 
caseCondition -:target-> value : EnumConstant ; 

modify { 

eval i transition . trigger = value . name ; } 

} 

} 

rule addTriggerCat chBlockExceptionClassName 
{ 

transition : Transition -:link-> catchBlock : CatchBlock ; 

catchBlock -: parameter -> parameter : OrdinaryParameter ; 

parameter -:typeRef erence -> nspClassRef : Name spaced ass if ierRef erence: 
nspClassRef - : classif ierRef erence s -> classRef : Classif ierRef erence ; 
classRef -:target-> exceptionClass : Class ; 

modify { 

eval { transition . trigger = exceptionClass . name ; }■ 

} 

} 

rule addTriggerOtherwise 
{ 

transition: Transition; 

if {. transition . trigger == null II transition . trigger == ""; > 
modify { 

eval { transition . trigger = "--"; } 

} 

} 



Figure 4: Rules for extension task 1 
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rule addActionSend 
{ 

trans it ion : Trans it ion -:link-> block : StatementListContainer ; 
block -: statements -> exprStmt : ExpressionStatement ; 
exprStmt -: expression -> callMethod : MethodCall ; 

callMethod -:target-> method : ClassMethod ; 

callMethod -: arguments -> enumClas sRef : Ident if ierRef er ence ; 
enumClassRef -:next-> enumValueRef : Identif ierRef erence ; 
enumValueRef -: target -> enumValue : EnumConstant ; 
if ■[ method . name == "send"; } 

modify { 

eval {. transition . action = enumValue . name ; } 

} 

} 

rule addActionOtherwise 
{ 

transition: Transition; 

if { transition . action == null II transition . action == ""; }■ 

modify { 

eval {. transition . action = > 

} 

} 



Figure 5: Rules for extension task 2 
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Figure 6: The resulting state machine, with an edge selected and its attributes displayed 



Edgar Jakumeit and Sebastian Buchwald 



179 



lie Edit Vievj Naviigale Layout He-lp 



D S35B7:! 
D S35BD- 
D S35C5,; 
D S35C9-slaIemac 
DJ35CF, 
D iSSDe.staleniac 
D i35Qftslateiiiac 

□ I35DE-. 

□ S35EC: 
DS35F3. 
Q laBFastalamai; 

□ K3603,stalemaC 

□ S3609,3talemaC 

□ SSBIS-Statei 

D -5351 F,3t ale mac 

□ S3S27;5!^emaC 

D 
□ 

D 43538-: 
DS3643?st^ei 

D 

D$3653st 

□ S3B5B-; 

D S3BB9 SI 
D S3671 st 
D i3B77.staleniaC . 
D iSETDislateniac 

D weaBTBtalemac 
BBadas5insis_a; 
ESC^d assifieiB_Cl 
EBDdassifier3_a 
B^-tia33ifiers_Cl a) 
EBF.das£iners_a; 
ET1:da55ltiera_ai 



"-G^Ei 

■-a El 



"^fi#ii|i^rt^ i.i—M'| l I I I m 

f t 



Figure 7: The program graph, the rectangles are the classes, the top one is the state machine 
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Figure 8: The program graph zoomed with the class SynSent and the state machine 




Figure 9: The program graph zoomed further to the method run of the class SynSent 
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Figure 10: An excerpt from the configuration of the layout 



